Wiki Notes

Appearance

04B. MCP 协议与连接器接入 ​

版本：v1.2

最后更新：2026-07-09

适用对象：正在评估如何把企业知识、SaaS、内部系统和 Agent 工具按统一协议接出去的产品、平台、架构与基础设施同学

1. 为什么 MCP 要单独讲 ​

很多团队把 MCP 理解成“另一种工具调用方式”，这会把问题讲得太浅。

更准确地说，MCP 解决的是：

  • 不同外部能力如何按统一协议暴露给 Agent
  • host、client 和 server 之间如何分工
  • tools、resources、prompts 如何被发现、读取和调用
  • 接入层如何从“某个项目的私有封装”升级成“多宿主可复用的标准暴露层”

所以 MCP 不只是一个 Tool 名称集合，而是能力暴露和互操作的协议层。

2. MCP 到底回答什么问题 ​

最短的一句话可以这样理解：

  • MCP = 把外部能力标准化暴露给 AI 宿主和 Agent 运行时的协议层

它主要回答五个问题：

  1. 哪些能力可以被暴露
  2. 这些能力以什么对象形态暴露
  3. host、client、server 各自负责什么
  4. 如何做协议版本和能力协商
  5. 如何在不同 server 之间保持一致接入方式

根据 MCP 官方架构文档，MCP 的核心原语不是 Skill，而是：

  • tools
  • resources
  • prompts

这点很重要，因为它说明：

  • Skill 不是 MCP 标准层的固有对象
  • Skill 更像平台或应用层对 MCP 能力的再封装

2.1 先把 host、client、server 三层分清 ​

MCP 官方架构最值得团队建立的一层心智模型，其实不是“又多了一种工具”，而是：

  • host：AI 应用本体，负责容器、用户同意、上下文聚合和安全策略
  • client：host 为某个特定 server 创建的协议客户端
  • server：真正暴露 tools / resources / prompts 的能力提供方

比较稳的理解方式通常是：

层级更像什么角色负责什么
Host总控与容器生命周期、授权决定、上下文聚合、安全策略
Client单条连接适配层建连、会话、能力协商、消息路由
Server能力提供方暴露资源、工具、提示入口

这层区分非常重要，因为很多工程误判都来自这里：

  • 以为 server 自己负责所有用户权限
  • 以为 tool 暴露范围应该放在 prompt 里决定
  • 以为任意两个 MCP server 之间天然共享上下文

2.2 MCP 是有状态 session 协议，不只是“发一个请求” ​

根据 MCP 官方 architecture 和 lifecycle 文档，MCP 构建在 JSON-RPC 之上，但它不是“一来一回的无状态工具调用协议”，而是：

  • 一个围绕 capability negotiation、state management 和 context exchange 设计的有状态 session 协议

它的工程含义很大：

  • 你不能只想着“工具能不能 call 通”
  • 还要想着“这个会话协商出了哪些能力”
  • 以及“断线、重连、resume、审批恢复时，状态怎么延续”

2.3 初始化、能力协商和生命周期不是可有可无的边角 ​

MCP lifecycle 强调的主线通常是：

  1. 初始化
  2. 版本协商
  3. capability negotiation
  4. 正常运行
  5. 关闭或恢复

这意味着工程上不要默认：

  • 任何 client 都支持 sampling、elicitation、tasks
  • 任何 server 都支持 subscribe、listChanged 或 completions
  • 只要“连上了”，能力就一定能用

更稳的做法通常是：

  • 把“可连通”与“可用能力集合”分开看
  • 在观测里记录 negotiated capabilities
  • 把协商失败与普通网络失败区分开

2.4 用同一个例子，把 MCP 单独看清 ​

还是拿“事故分诊”举例：

  • 如果你在设计 read_recent_alerts 这个动作的参数和错误结构，你在做 Tool
  • 如果你在设计“把告警系统、runbook 文档和值班模板统一暴露给多个 AI 宿主”，你在做 MCP
  • 如果你在设计“事故分诊这个任务什么时候先查告警、什么时候升级给人工”，你在做 Skill

所以 MCP 最核心的价值不是“多了一种调用方式”，而是：

  • 让多个宿主用相同方式发现和接入能力
  • 让 tools / resources / prompts 成为统一暴露面
  • 让认证、会话、能力协商和信任边界有了清楚落点

3. MCP 最核心的三个对象 ​

3.1 Tools ​

适合暴露“可执行动作”：

  • 查工单
  • 新建任务
  • 获取告警
  • 触发检索

它回答的是：

  • 系统到底能做什么动作

3.2 Resources ​

适合暴露“可读取上下文或内容对象”：

  • 文档
  • 配置
  • 数据快照
  • 结构化记录

它回答的是：

  • 系统里有哪些可供消费的上下文对象

3.3 Prompts ​

适合暴露“可复用的提示模板或交互入口”。

它解决的是：

  • 某类标准交互应该如何被初始化

但要注意：

  • prompt 不是完整的 Skill
  • prompt 更像可复用模板
  • skill 更像场景级封装包

3.4 Resources 不只是“给模型看点文本”，还有 list / read / template / subscribe ​

很多团队第一次看 MCP resources，会把它简单理解成“拿一段上下文给模型”。

但按 MCP 官方 resources 规范，它至少覆盖四类能力：

  1. resources/list 用来发现当前有哪些资源对象
  2. resources/read 用来按 URI 读取具体内容
  3. resources/templates/list 用来暴露参数化资源模板
  4. subscribe / listChanged 用来感知资源内容或资源列表变化

这说明 resources 更像：

  • “可寻址的上下文对象层”

而不只是：

  • “某个工具顺手返回的一段文本”

3.5 Tools 和 Resources 最好不要互相伪装 ​

一个很实用的判断方式是：

  • 要“做动作”，更像 tool
  • 要“读对象”，更像 resource

比如：

  • 读取固定 runbook、schema 文档、租户配置，通常更适合作为 resource
  • 触发重新索引、创建工单、写变更记录，通常更适合作为 tool
  • 查询某个长期可寻址业务对象，到底是 tool 还是 resource，要看你是否希望它成为稳定 URI 对象

如果团队不分这条边界，后面经常会在：

  • 权限模型
  • 缓存策略
  • 订阅更新
  • 评测回放

这些地方一起变乱。

4. OpenAI 体系里 MCP 和 Connectors 的位置 ​

OpenAI 当前把 MCP and Connectors 单独作为一层工具接入能力来讲，核心意义在于：

  • 不只支持本地 function calling
  • 还支持通过标准协议或连接器接入远端能力

工程上可以把它理解成三层：

层级更关心什么
Tool单个能力契约是否清晰
MCP这些能力是否按统一协议暴露与认证
Connector某个现成外部系统是否已经有可复用接入层

4.1 在 OpenAI Responses API 里，connectors 和 remote MCP 都走 mcp 工具类型 ​

OpenAI 当前官方 MCP and Connectors 指南里，一个很关键但容易漏掉的事实是：

  • connectors 和 remote MCP servers 都通过 mcp 这个 built-in tool type 接进 Responses API

只是传参不同：

方式关键入参典型适用场景
Remote MCP serverserver_url你要接公开可访问的 MCP server
Connectorconnector_id你要接 OpenAI 维护的现成外部服务接入层

这意味着：

  • 运行时调用链长得很像
  • 但 ownership、信任边界和接入责任并不一样

4.2 OpenAI 的真实运行链路不是“直接 call”，而是先 mcp_list_tools 再 mcp_call ​

OpenAI 当前官方文档把这条链路讲得很明确：

  1. 先把 remote MCP server 或 connector 注册到 tools
  2. API 先去列出该 server 暴露的工具
  3. 返回 mcp_list_tools output item
  4. 模型基于导入后的 tool definitions 决定是否调用
  5. 真正调用时生成 mcp_call
  6. 如果需要审批，还会先生成 mcp_approval_request

这个心智模型非常关键，因为它回答了三个常见误区：

  • 模型一开始并不知道远端所有细节，它先看到的是导入后的 tool definitions
  • MCP 接入的第一个成本不是执行，而是“工具清单导入”
  • 审批点并不一定只在业务工具本体里，也可能体现在 OpenAI 这一层的 approval flow

4.3 allowed_tools、require_approval 和 defer_loading 是运行时治理重点 ​

根据 OpenAI 当前官方文档，MCP 接入层特别值得团队关注三个运行参数：

  • allowed_tools 控制远端 server 上哪些工具可被暴露
  • require_approval 控制哪些调用必须显式批准，哪些可以自动通过
  • defer_loading 在配合 tool search 时，允许先不把整个 server 的工具面一次性都载入

这三者分别对应三类完全不同的问题：

  • allowed_tools 解决“暴露面过大”
  • require_approval 解决“高风险动作如何收口”
  • defer_loading 解决“工具很多时的上下文与成本问题”

4.4 一个最小 remote MCP 接入长什么样 ​

按 OpenAI 当前 MCP and Connectors 文档的接口形态，remote MCP server 在 Responses API 里更像这样：

python
from openai import OpenAI

client = OpenAI()

resp = client.responses.create(
    model="your-model",
    tools=[
        {
            "type": "mcp",
            "server_label": "incident_ops",
            "server_url": "https://incident.example.com/mcp",
            "allowed_tools": ["read_recent_alerts", "search_runbook"],
            "require_approval": "never",
            "defer_loading": True,
        }
    ],
    input="先检查最近 30 分钟的支付告警，并总结可能原因。"
)

这个例子里最关键的不是 SDK 语法，而是你已经能一眼看出：

  • 暴露的是一个 mcp 接入点，不是单个 function tool
  • 运行时可以只放行部分工具
  • 工具很多时可以延迟加载
  • 审批策略可以在接入层就先收住

4.5 Connector 和 remote MCP 很像，但 ownership 不一样 ​

OpenAI 当前官方文档已经把这点讲得很清楚：

  • connector 是 OpenAI 维护的 MCP wrapper
  • remote MCP server 则可以是任何实现了 remote MCP 的远端服务

所以两者虽然都通过 mcp 这类 tool 接入，但你最好分清：

  • 谁在维护 server
  • 谁在承担认证与信任责任
  • 谁在对结果质量和权限边界兜底

5. 什么时候适合上 MCP ​

下面这些情况通常很适合考虑 MCP：

  • 同一批企业能力要被多个 Agent 或多个宿主复用
  • 你希望把工具、资源和提示入口统一暴露
  • 接入层和业务层需要明确分工
  • 你不想在每个项目里各自维护一套私有工具协议

反过来，如果只是：

  • 一个很小的单体应用
  • 少量本地工具
  • 没有复用诉求

那先把本地 Tool 契约收好，往往比过早上协议层更直接。

5.1 function calling、remote MCP、connector 到底怎么选 ​

这三者不是互斥关系，但最好不要混着说。

一个比较稳的选型表通常是：

方案你主要在解决什么问题更适合什么情况
Function calling把你自己的应用动作暴露给模型单项目、第一方、边界最清晰
Remote MCP按统一协议接标准化远端能力多宿主复用、第一方或官方 server
Connector快速接入 OpenAI 已维护的外部服务封装常见 SaaS、想减少自建接入成本

一个很常见的正确组合其实是：

  • 本项目核心业务能力仍然用 function calling
  • 标准化外部能力走 remote MCP
  • 通用 SaaS 优先看 connector

这样既不会把企业私有接口一股脑全丢进远端协议层，也不会每接一个 SaaS 都自己重写一遍。

6. MCP 最常见的边界误解 ​

6.1 误把 MCP 当成 Tool 的同义词 ​

不是。

  • Tool 是能力本身
  • MCP 是能力如何暴露

6.2 误把 MCP 当成“自动解决权限问题” ​

也不是。

MCP 能统一接入方式，但不会替你自动完成：

  • 最小权限设计
  • 审批策略
  • 风险分级
  • 业务侧幂等与补偿

这些仍然要回到 Tool 契约和运行时治理里。

6.3 误把“接上 MCP”当成“已经能稳定生产化” ​

真正上线还要回答：

  • 哪些 server 可用
  • 哪些工具可被暴露
  • 哪些 resources 可被读取
  • 哪些返回内容属于低信任内容
  • 哪些操作必须经过人工确认

6.4 误把 transport 当成“无关紧要的底层细节” ​

MCP 官方 transports 和 authorization 文档实际上把很多重要边界写得很清楚：

  • stdio 更适合本地子进程式 server
  • Streamable HTTP 更适合远端、多 client、可流式和可通知的 server

更关键的是，两者安全假设并不一样：

  • HTTP 场景里要认真看 Origin 校验、认证、session header 和 resumability
  • stdio 场景里则更像本机受控进程，授权通常从环境或宿主控制层拿

如果团队把 transport 只当成“SDK 帮我们处理了”，后面很容易漏掉：

  • 断线重连怎么恢复
  • session 怎么续
  • 本地 server 为什么不该照搬 HTTP OAuth 设计
  • 远端 server 为什么需要更严格的 origin / auth / timeout 策略

6.5 误把能力协商看成“连上就能用全部功能” ​

MCP lifecycle 明确要求：

  • 初始化必须先做协议版本协商
  • 然后做 capability negotiation
  • 后续运行阶段只能使用已经成功协商出来的能力

这意味着工程上不要默认：

  • 任何 client 都支持 sampling、elicitation、tasks
  • 任何 server 都支持 listChanged、subscribe、completions

更稳的做法通常是：

  • 把“可连通”与“可用能力集合”分开看
  • 在日志和观测里记录 negotiated capabilities
  • 不要把协商失败误判成普通网络错误

7. MCP 和安全、审计、信任边界的关系 ​

MCP 一旦接入外部世界，风险面会明显扩大。你至少要明确：

  • 哪些 server 是第一方
  • 哪些 server 是第三方
  • 哪些返回结果属于低信任内容
  • 哪些调用会触发写操作或跨系统副作用

这会直接影响：

  • 日志该落在哪层
  • 审批该落在哪层
  • 结果是否可以直接回灌模型
  • 工具结果是否要先经过清洗与标注

所以 MCP 设计的重点从来不只是“连上了没有”，而是“连上以后边界清不清”。

7.1 Prompt injection 和 URL 二次传播是 MCP 接入里的高频真实风险 ​

OpenAI 当前官方 MCP and Connectors 指南在风险部分专门强调了几类问题：

  • prompt injection
  • 对敏感动作始终保留 approval
  • 小心使用 MCP 返回里的 URL 或图片 URL
  • 优先连接服务提供方官方托管的 server

这意味着团队不应该只做“连通性测试”，还应显式评估：

  • 低信任文本会不会污染后续推理
  • server 输出的 URL 会不会被直接嵌入前端或再次抓取
  • 聚合代理型 server 会不会比官方 server 多一层数据暴露面

7.2 “信任这个 server”不等于“信任它返回的所有内容” ​

这条在企业系统里尤其容易被误用。

即便一个 server 本身是可信接入层，它返回的具体内容也可能仍然是：

  • 用户生成文本
  • 第三方网页内容
  • 跨租户或跨系统拼接结果
  • 带恶意提示注入的文档片段

所以最稳的做法通常不是“这个 server 可信，所以原样回灌”，而是：

  • 按来源标记信任等级
  • 对结果做清洗、截断、白名单化和结构化
  • 对高风险输出保留人工确认或二次校验

8. MCP、Tool、Skill 怎么分工最顺 ​

比较稳的分工方式通常是：

8.1 Tool owner ​

负责：

  • 单个能力接口
  • 输入输出契约
  • 失败处理和副作用边界

8.2 MCP server owner ​

负责：

  • 能力暴露方式
  • tools / resources / prompts 组织
  • 认证与连通性
  • server 可复用性和稳定性
  • 协议版本升级窗口
  • 能力协商兼容性
  • session / transport 运行约束

8.3 Skill 或应用 owner ​

负责：

  • 任务入口
  • 上下文装配
  • 允许哪些工具和哪些 server 可见
  • 某类任务里的执行策略和输出契约

也就是说，真正成熟的系统通常不会让应用 owner 直接背：

  • 单个 tool schema 细节
  • transport 细节
  • OAuth 发现细节

但会让应用 owner 明确：

  • 哪类任务允许连接哪类 server
  • 任务中是否允许自动批准
  • 哪些 server 结果可以进入模型上下文
  • 哪些 server 只允许做人工辅助检索

如果这三层 owner 不分，系统通常会慢慢变成：

  • 工具定义散在业务代码里
  • 协议接入散在项目配置里
  • 场景经验散在 prompt 和 wiki 里

9. 什么时候不一定要上 Connector ​

如果某个系统已经有现成 connector，这当然能降低接入成本。但不是所有场景都应该优先 connector。

更适合 connector 的情况通常是：

  • 外部 SaaS 已经有稳定接入层
  • 你主要关心复用现成连接器能力
  • 宿主平台已经内建 connector 管理

更适合自建 MCP server 的情况通常是：

  • 企业内部能力很多
  • 需要统一第一方能力暴露标准
  • 需要自己管审计、鉴权、可用性和租户边界

9.1 私有、内网或本地 server 不一定要暴露到公网 ​

OpenAI 当前官方资料里已经把这件事单独拎出来讲：

  • 如果 MCP server 是 private、on-premises 或 behind a firewall，可以用 Secure MCP Tunnel

这对企业环境很关键，因为很多团队的错误前提是：

  • “要给 OpenAI 用，就得先把 server 直接暴露到公网”

但更合理的思路通常是：

  • 公网官方 server：优先直接接
  • 私有企业 server：优先通过受控隧道或内网接入策略暴露
  • 高风险内网能力：不要因为“为了方便接模型”就先把网络边界放开

9.2 连接官方 server 往往比连接聚合代理更稳 ​

OpenAI 当前官方风险部分明确建议，优先连接服务提供方自己托管的官方 server。

这条建议背后的原因其实很朴素：

  • 少一层代理，就少一层数据暴露和行为不确定性
  • 官方 server 往往更清楚自身 API 语义、权限边界和版本演进
  • 聚合代理服务经常把多个上游能力揉成一层，审计和责任界面更模糊

10. MCP 的落地检查清单 ​

  • 是否已经分清 tools、resources、prompts 三类对象
  • 是否明确了哪个能力该通过 MCP 暴露，哪个只保留本地 Tool
  • 是否区分了第一方 server 和第三方 server 的信任等级
  • 是否明确了认证、授权、审批和审计分别落在哪层
  • 是否规定了外部返回内容的清洗和回灌策略
  • 是否已经把 MCP 讨论和 Tool 契约讨论分开
  • 是否记录了 negotiated capabilities，而不是只记录“已连通”
  • 是否根据 stdio / Streamable HTTP 选择了对应的认证、session 和恢复策略
  • 是否给高风险 server 配置了 allowed_tools、require_approval 或等价控制
  • 是否评估了 prompt injection、URL 二次传播和第三方聚合代理风险

11. 推荐联读 ​

12. 参考资料 ​